I'm sorry but I don't think this is worth the extra complexity when we already have a prime-caches subcommand.

Thanks for looking at this. The prime-caches subcommand is great for testing the raw database caching, but it bypasses the main_loop completely. It doesn't run the actual LSP server, the VFS progress sync, or the flycheck background tasks. I can be convinced that the benchmark doesn't add a ton of value, since regressions are somewhat more likely to come from the interaction of all those things, rather than the code path the benchmark covers, but I'd argue the log point still makes it quite a bit easier to get timing measurements in a significant spot when profiling the launch experience more holistically, for very modest added complexity.

It still loads all files into the VFS and runs Cargo. We don't have much more than that.

But since you disagree, let's ask: @rust-lang/rust-analyzer does someone do want this?

Yea I don't think this is too useful either, having an fino log when done with workspace loading etc seems fine to me though, but anything other than that is unnecessary if you ask me

So you're saying keep the log point and nix the benchmark? I'm ok with that.

Yea but without the time tracking, just have a log for startup, and a log for whenever we load a workspace, the default logger has timestamps already after all